Network Working Group Keith Moore Internet Draft University of Tennessee 16 September 1993 MIME Content-Types For Delivery Status Notifications draft-moore-mime-delivery-00.txt 1. Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. (The file 1id-abstracts.txt, available via anonymous ftp from nic.ddn.mil, describes the current status of each Internet Draft.) It is not appropriate to use Internet Drafts as reference material or to cite them other than as "work in progress". 2. Abstract This memo defines a message format which may be used by a message transfer agent (MTA) or internetwork mail gateway to report the result of an attempt to deliver a message to one or more recipients. The message format utilizies several MIME content-types which are also defined by this memo. 3. Introduction The SMTP protocol [1] requires that an SMTP server provide notification of delivery failure, if it determines that a message cannot be delivered to one or more recipients. Traditionally, such notification consists of an ordinary Internet mail message (in the format defined by [2]), sent to the envelope sender address (supplied with the SMTP MAIL command), containing a human-readable explanation of the error, and at least the headers of the failed message. Experiences with large mail distribution lists [3] indicates that such messages are often insufficient to diagnose problems, or even to determine at which host or for which recipients a problem occurred. In addition, the lack of a standardized format for delivery notifications in Internet mail makes it difficult to exchange such notifications with other message handling systems. This memo defines a MIME [4] based protocol for delivery status notifications (DSNs) in Internet mail. This protocol can be used to notify the sender of a message of any of several conditions: successful K. Moore Expires 16 March 1994 [Page 1] Delivery Status Notifications 16 September 1993 delivery, failed delivery, message forwarding, or the gatewaying of a message into an environment that may not support DSNs. NOTE: A Delivery Status Notification (DSN) is different from a Receipt Notification (RN). A DSN is issued by the mail transport system, and indicates whether a message was successfully delivered to a recipient's mailbox. A DSN conveys no information about what happens to the message after it has reached the mailbox. An RN is issued by a recipient's mail reader or message store, and conveys information about whether a message has been read by the recipient. This memo defines the format of a DSN. An extension to the SMTP protocol to request DSNs is the subject of another memo [5]. Neither of these protocols support receipt notifications. As of this writing, protocols for RNs and requests-for-RNs is are yet to be defined. 4. The multipart/delivery-status-notification MIME content-type The multipart/delivery-status-notification content-type is defined as follows: MIME type name: multipart MIME subtype name: delivery-status-notification Required parameters: same as in multipart/mixed Optional parameters: none Encoding considerations: same as in multipart/mixed Security considerations: see section 7 of this memo. The multipart/delivery-status-notification content-type is to be used as the top-level content type for any DSN. This content-type up to three sub-parts, in the following order: (1) [required] A text/plain body part containing explanatory text. This text may be in any MIME-standard charset. (2) [required] A message/delivery-report body part containing the details of the failed or successful delivery. (3) [optional] A message/rfc822-fragment body part containing the returned contents. If the "returned contents" body part is present, a Content-ID header should be associated with this body part, and the "returned-content" parameter of the message/delivery-report body part should indicate the content-id of the returned contents. K. Moore Expires 16 March 1994 [Page 2] Delivery Status Notifications 16 September 1993 5. The message/delivery-report MIME content-type The message/delivery-report content-type is defined as follows: MIME type name: message MIME subtype name: delivery-report Required parameters: none Optional parameters: id, returned-content, charset Encoding considerations: Any content-transfer-encoding may be used. 7BIT is recommended unless an alternate charset is required; otherwise, use an appropriate encoding for that charset. Security considerations: discussed in section 7 of this memo. The "id" parameter contains the envelope message-id of the message for which the report is being generated (which may or may not be the same as the message-id header). If the message containing the delivery-report contains the returned message, the "returned-content" parameter specifies the MIME content-id of that message. If no "returned-content" parameter is supplied, the content is not returned. The "charset" parameter is optional. If it appears, it applies only to the "text" fields of the delivery-report, and only if these fields are written using the "alternate charset" mechanism defined by STIF. At any rate, such charsets must be registered for use with the MIME "text/plain" body part type. The body of the delivery-report consists of one or more (per- recipient) records formatted according to STIF [6]. Each record consists of the following fields: orig-rcpt The Internet mail address of the recipient, as originally specified by the sender. [optional] rcpt The electronic mail address of the recipient, from the message envelope presented to the MTA or gateway issuing the report. [required if orig-rcpt is not present] mta The Internet domain name of the MTA or gateway generating the report. For MTAs and gateways not on the Internet, a unique name that reflects the location of the MTA or gateway may be used. [required] date The date of the delivery attempt, in RFC 822 "date-time" format. [required for "delivered", "relayed", or "forwarded" reports, optional for "failed" reports] K. Moore Expires 16 March 1994 [Page 3] Delivery Status Notifications 16 September 1993 action One of "delivered", "failed", "relayed", or "forwarded". [required] An action value of "delivered" indicates that the message has been successfully delivered to the recipient address specified by the sender. (This includes "delivery" to a distribution list expander.) A value of "failed" indicates that the message could not be delivered to the recipient. A value of "relayed" indicates that the message has been relayed or gatewayed into an environment that does not accepted responsibility for generating delivery reports that conform to this specification. A value of "forwarded" indicates that the message has been delivered to the recipient address as specified by the sender, and forwarded beyond that destination to one or more additional addresses. The keywords "delivered", "failed", "relayed", and "forwarded" may be spelled in any combination of upper and lower case characters. status A 3-digit SMTP reply-code, indicating the delivery status for that recipient. Normally this will be the reply-code returned by an SMTP server in response to a RCPT command. Reply-codes are defined in [1], [5], [7], [8], and other SMTP service extension documents. If none of these reply codes is appropriate, any of "200", "400", or "500" may be used to indicate success, "temporary" failure, or "permanent" failure, respectively. [optional] text Text describing the error. This field ONLY may be in the character set specified by the "charset" parameter of the body part, if it is written using the "alternate charset" mechanism of STIF. If the alternate charset mechanism is not used, or if the charset parameter does not appear, the text must be in US-ASCII. [optional] tag Additional information which may be used by internetwork mail gateways to allow mapping of DSNs to and from similar services in other environments. The contents of the tag are defined by the protocol used to request delivery reports. [optional] 6. Conformance and Usage Requirements An MTA or gateway conforms to this specification if it generates DSNs according to the format defined here. For MTAs and gateways that do not K. Moore Expires 16 March 1994 [Page 4] Delivery Status Notifications 16 September 1993 support requests for delivery notification (such as in [5]), it is sufficient that delivery failure reports use this format. An MTA or gateway should NOT generate "delivered", "relayed", or "forwarded" DSNs unless specifically requested by the sender, via the SMTP extension defined in [5] or some other MTA-level protocol. MTAs and gateways should not use the "orig-rcpt" field of the message/delivery-report content-type unless the mail transfer protocol ensures that the address provided is that originally specified by the sender of the message. (Ordinary SMTP does not make that guarantee; the SMTP extension defined in [5] does.) DSNs must be returned to the sender of the message, in such a way that the notification itself will not "bounce" if delivery of the notification fails. (In SMTP, this is accomplished by using an empty string as the sender address in the MAIL command.) This specification places no restrictions on the use of delivery notifications by recipient user agents or distribution lists. 7. The message/rfc822-fragment content-type The message/rfc822-fragment content-type is defined as follows: MIME type name: message MIME subtype name: rfc822-fragment Required parameters: none Optional parameters: none Encoding considerations: any standard MIME content-transfer- encoding may be used. Security considerations: none A message returned in a DSN may have been truncated for any of several reasons. If such a message were packaged in a message/rfc822 content-type, a missing final boundary marker might confuse MIME mail readers. The message/rfc822-fragment content-type is used to label an RFC 822 (or MIME) message which may not be complete. Unlike a message/rfc822 content-type, the message/rfc822-fragment content-type is opaque to the mail system. In general, mail handling software should not assume that such a body part is well-formed according to either RFC 822 or MIME. Gateways are specifically prohibiting from "taking apart" and translating a message/rfc822-fragment message and performing operations on its component parts. When necessary, a gateway may apply a content- transfer-encoding to the entire contents of an unencoded message/rfc822-fragment body part, but it must not attempt to perform such transformations on the individual components of the body part. K. Moore Expires 16 March 1994 [Page 5] Delivery Status Notifications 16 September 1993 8. Security considerations Delivery notifications may be forged as easily as ordinary Internet electronic mail. User agents and automatic mail handling facilities (such as mail distribution list expanders) that wish to make use of such notifications, should take appropriate precautions to minimize the potential damage from denial-of-service attacks. 9. References [1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, USC/Information Sciences Institute, August 1982. [2] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, UDEL, August 1982. [3] Westine, A., Postel, J. "Problems with the Maintenance of Large Mailing Lists.", RFC 1211, USC/Information Sciences Institute, March 1991. [4] Borenstein, N., Freed, N. "Multipurpose Internet Mail Extensions", RFC 1341, Bellcore, Innosoft, June 1992. [5] Moore, K. "SMTP Service Extension for Delivery Reports", Internet Draft "draft-moore-smtp-drpt-00.txt", 16 September 1993. [6] Crocker, D. "Structured Text Information Format (STIF)", Internet- Draft "draft-crocker-stif-00.txt", June 1993. [7] Klensin, J., Freed, N., Rose, M., Stefferud, E., Crocker. D. "SMTP Service Extensions." RFC 1425, United Nations University, Innosoft International, Inc., Dover Beach Consulting, Inc., Network Management Associates, Inc., The Branch Office, February 1993. [8] Klensin, J., Freed, N., Moore, K. "SMTP Service Extension for Message Size Declaration." RFC 1427, United Nations University, Innosoft International, Inc., University of Tennessee, February 1993. K. Moore Expires 16 March 1994 [Page 6] Delivery Status Notifications 16 September 1993 10. Author's address Keith Moore University of Tennessee 107 Ayres Hall Knoxville, TN 37996-1301 USA email: moore@cs.utk.edu K. Moore Expires 16 March 1994 [Page 7] Delivery Status Notifications 16 September 1993 Appendix: Example delivery notification From: postmaster@netlib2.cs.utk.edu To: j.random.user@cs.utk.edu Subject: delivery notification Content-type: multipart/delivery-notification; boundary=xyzzy MIME-Version: 1.0 --xyzzy Content-type: text/plain; charset=us-ascii Your mail message could not be delivered to some of the recipients listed below. The message has been returned to you. --xyzzy Content-type: message/delivery-report; id="<930624.AA09834@cs.utk.edu>"; returned-content="<0xffcc8090@netlib2.cs.utk.edu>" < orig-rcpt: bogus.user@netlib2.cs.utk.edu; status: 550; by: netlib2.cs.utk.edu; date: Thu, 24 Jun 1993 18:43:03 -0400; action: failed; text: : no such user; > < orig-rcpt: remote.user@netlib2.cs.utk.edu; by: netlib2.cs.utk.edu; date: Thu, 24 Jun 1993 18:43:04 -0400; action: relayed; text: next-hop MTA does not support delivery reports;> < orig-rcpt: big-mailing-list@netlib2.cs.utk.edu; by: netlib2.cs.utk.edu; date: Thu, 24 Jun 1993 18:43:07 -0400; action: delivered; text: message sent to list recipients;> < orig-rcpt: moore@netlib2.cs.utk.edu; by: netlib2.cs.utk.edu; date: Thu, 24 Jun 1993 18:43:07 -0400; action: forwarded; text: message forwarded to ;> --xyzzy MIME-Version: 1.0 Content-type: message/rfc822 Content-id: <0xffcc8090@netlib2.cs.utk.edu> Received: by netlib2.cs.utk.edu; Thu, 24 Jun 1993 18:43:03 -0400 To: bogus.user@netlib2.cs.utk.edu, remote.user@netlib2.cs.utk.edu, big-mailing-list@netlib2.cs.utk.edu, moore@netlib2.cs.utk.edu From: j.random.user@cs.utk.edu Date: Thu, 24 Jun 1993 18:42:09 -0400 Subject: quote Message-id: <930624.AA09834@cs.utk.edu> "Don't sweat it -- it's not real life. It's only ones and zeroes." -- spaf --xyzzy-- K. Moore Expires 16 March 1994 [Page 8]